From now on, for dynamically-typed scenarios, callers of Search need to use
DocumentSearchResult<Document> and SearchResult<Document> instead. This will
make it easier to transition the implementation of this API to generated
code.

This is a breaking change to facilitate more generated code in the SDK. Facet
results are now typed as IDictionary<string, IList<FacetResult>> and hit
highlights as IDictionary<string, IList<string>>.

…utable

…Token

Added remarks to the comments for SearchContinuationToken that call out its
ability to be serialized to and from JSON.

This change introduces new generated code and replaces most custom model
class code with generated models, but it does not yet switch over the
implementation of Search to use the new generated code.

This is a temporary step on the way to replacing the custom implementation of
Search with generated code. This change streamlines the process of
deserializing search results by:
  - Removing the unnecessary intermediate DocumentSearchResponsePayload class
  - Moving the logic to build SearchContinuationTokens into
    DocumentSearchResult
  - Passing JsonSerializerSettings to the core operation methods instead of
    passing lambdas

Since DocumentSearchResponsePayload is gone, I also took the opportunity to
make SearchContinuationTokenPayload a private nested class of
SearchContinuationTokenConverter.

Also remove functionality from SearchParameters that isn't used anymore.

Also fixing some Java-isms in a test.

This required some very hacky regexes to customize the generated code, but it
works. Also, it's better than having to parse URL query strings to
reconstitute a SearchParameters instance, since that would miss custom
parameters that can't be modeled in Swagger, like personalization IDs for
custom ranking.

Ideally we'll find a pattern common to other data plane APIs so we don't have
to hack this with regexes for every target language, but it's good enough for
now.

…on-null

Also renamed some properties for consistency.